1/1 


MICROCOPY  RESOLUTION  TEST  CHART 
NATIONAL  BURtAU  OF  STANDARDS- ]  %j  A 


AD-A141  514 


Martin  S.  Feather 


IS  I  Reprint  Scries 

ISI/RS-SJ- 1*2: 

April 


University 


of  Southern 
California 


Reuse  in  the  Context  of  a 
Transformation  Based  Methodology 


Reprinted  from  Proceedings  of  the  Workshop  on  Reusability 
in  Programming ,  Newport,  Rhode  Island,  7-9  September  1983. 


CL. 

O 


MAY  1  5  1984  .j 


,pr-ved 
.  ai-v.  i's 


INFORMATION 
SCIENCES 
INSTITUTE 


'LEU 


213/822-1511 

4676  Admiralty  Way/Marina  del  Rey/California  90292-6695 


ad  05  15  221 


SECURITY  CLASSIFICATION  of  This  PAGE  ( When  Data  Entared) 


REPORT  DOCUMENTATION  PAGE 


1.  REPORT  number 

ISI/RS-83-125 


READ  INSTRUCTIONS 
BEFORE  COMPLETING  FORM 


4.  TITLE  (and  Subtitle) 


5.  TYPE  OF  REPORT  ft  PERIOD  COVERED 


Reuse  in  the  Context  of  a  Transformation  Based  Methodology  Research  Report 


6.  PERFORMING  ORG.  REPORT  NUMBER 


7.  AUTHORft; 


Martin  S.  Feather 


0.  CONTRACT  OR  GRANT  NUMBERfA) 


MDA903  81  C  0335 


9-  PERFORMING  ORGANIZATION  NAME  AND  ADDRESS 

USC/Information  Sciences  Institute 

4676  Admiralty  Way 

Marina  del  Rey,  CA  90292-6695 


11.  CONTROLLING  OFFICE  NAME  AND  ADDRESS 

Defense  Advanced  Research  Projects  Agency 
1400  Wilson  Blvd. 

Arlington,  VA  22209 


10.  PROGRAM  ELEMENT.  PROJECT,  TASK 
AREA  ft  WORK  UNIT  NUMBERS 


12.  report  DATE 

April  1984 


13.  NUMBER  OF  PAGES 

15 


4.  MONITORING  AGENCY  name  a  ADDRESS  (It  dllterent  from  Conlrolllnt  Olltce)  IS.  SECURITY  CLASS,  (ol  thte  report) 

Unclassified 


ISa.  DECL  ASSI  FI  CATION/ DOWNGRADING 
SCHEDULE 


16.  DISTRIBUTION  STATEMENT  (ol  thle  Report) 


This  document  is  approved  for  public  release;  distribution  is  unlimited. 


17.  DISTRIBUTION  STATEMENT  (of  the  aba  tract  antarad  In  Block  20,  II  dlftarant  Irotn  Raport) 


IS.  SUPPLEMENTARY  NOTES 

This  report  is  a  reprint  of  a  paper  that  appears  in  the  proceedings  of  the  Workshop  on  Reusability  in 
Programming,  held  in  Newport,  Rhode  Island,  7-9  September  1983.  The  workshop  was  sponsored  by 
ITT  Programming,  Stratford,  Connecticut. 

10.  KEY  WOROS  (Contlnua  on  ravaraa  aida  II  nacaaaary  and  Idantlly  by  block  number ) 

maintenance,  program  development,  program  specification,  program  transformation,  reusability 


*0.  ABSTRACT  (Continue  on  ravaraa  tide  II  nacaaaary  an d  Identify  by  block  number) 


(OVER) 


DD  1473  COITION  OF  I  NOV  6S  IS  OBSOLETE 

S/N  0102*014-  6601 


Unclassified _ _ 

SECURITY  CLASSIFICATION  OF  THIS  RAGE  flWian  Data  Entered) 


Unclassified 


SECURITY  CLASSIFICATION  OF  THIS  R AOEfTWi»n  Data  Bnfrtd) 


20.  ABSTRACT 


Ottr  research  group  at  ISI  aims  to  improve  the  program  development  process  by  applying  program 
transformation  to  develop  implementations  for  specifications.  Following  this  methodology,  the 
development  of  a  piece  of  software  involves  its  specification  in  a  formal  specification  language,  and 
subsequent  machine-assisted  transformation  of  that  specification  into  an  implementation 
(conventional  program).  Subsequent  maintenance  and  modification  of  software  developed  in  this 
manner  is  achieved  by  modifying  the  specification,  and  reperforming  the  transformational 
development  to  derive  a  new  implementation.  Thus  reuse  occurs  through  reusing  the  original 
specification,  and  reusing  the  original  transformational  development  of  that  specification. 

-Got' approach  is  distinguished  by  the  nature  of  our  specification  language,  which  has  been  designed 
to  minimize  the  gap  between  informal  conceptualization  and  formal  specification.  A  beneficial  result 
of  this  is  that  maintenance  and  modification  at  the  specification  level  is  relatively  straightforward. 
Further,  the  techniques  that  we~8ppfy  in  transforming  specifications  into  implementations  are 
themselves  applied  repeatedly,  and  iserve  to  capture  our  programming  knowledge  in  a  conveniently 
reusable  manner.  Consideration  of  an  example  drawn  from  the  domain  of  process  control  illustrates 
these  points. 

/  \  .'T  t  *  if  t  1  ’  J 


Unclassified _ 

SECURITY  CLASSIFICATION  OF  THIS  RAOErRhFn  D«r»  Bnfrtd) 


ISI  Reprint  Series 
ISI/RS-83-125 

April  1984 


Martin  S.  Feather  ’ 


University 
of  Southern 
California 


Reuse  in  the  Context  of  a 
Transformation  Based  Methodology 


Reprinted  from  Proceedings  of  the  Workshop  on  Reusability 
in  Programming,  Newport,  Rhode  Island,  7-9  September  1983. 


a 


INFORMATION 

SCIENCES 

INSTITUTE 


fHJ 


213/822-1511 


4676  Admiralty  Way/M anna  del  Rey/California  90292-6695 


Thie  research  is  supported  by  the  Defense  Advanced  Research  Projects  Agency  under  Contract  No.  MDA903  81  C  0335  Views  and 
conclusions  contained  in  this  report  are  the  author's  and  should  not  be  interpreted  as  representing  the  official  opinion  or  policy  of  DARPA, 
the  U  S  Government,  or  any  person  or  agency  connected  with  them 


ISI  Reprint  Series 

This  report  is  one  in  a  series  of  reprints  of  articles  and  papers  written  by  ISI 
research  staff  and  published  in  professional  journals  and  conference 
proceedings.  For  a  complete  list  of  ISI  reports,  write  to 

Document  Distribution 
USC/Information  Sciences  Institute 
4676  Admiralty  Way 
Marina  del  Rey,  CA  90292-6695 


REUSE  IN  THE  CONTEXT  OF  A  TRANSFORMATION  BASED  METHODOLOGY 


MARTIN  S.  FEATHER 


y: 


USC  /  Information  Sciences  Institute 
4676  Admiralty  Way 
Marina  del  Rey  CA  90291 


1 .  A  DEVELOPMENT  METHODOLOGY 

At  ISl  we  are  researching  a  methodology  for  assisting  software 
development  It  is  our  firm  belief  that  to  make  significant  progress 
in  this  direction  we  must  formalize  record  and  manipulate  the 
development  process  itself  The  methodology  we  advocate  is  one 
of  constructing  a  formal  specification  expressing  desired 
(functional)  behaviour  and  then  transforming  this  into  an 
implementation  to  achieve  efficiency  whilst  preserving 
functionality. 


What  differentiates  our  research  from  that  of  others  pursuing 
this  transformational  approach  is  the  nature  of  our  specification 
language.  This  has  been  designed  to  minimize  the  distance 
between  informal  conceptualization  of  tasks  and  formal 
specifications  of  the  same.  A  consequence  of  this  is  that  the 
richness  of  our  specification  language  makes  automatic 
compilation  into  tolerably  efficient  programs  beyond  our  present 
capability  (and  to  restrict  ourselves  to  the  use  of  only  those 
specification  constructs  that  we  can  presently  compile  would,  we 
feel,  be  a  grave  mistake  for  our  or  any  other  specification 
language).  Hence  the  transformation  from  specification  to 
implementation  must  rely  upon  human  guidance  (although  it  can 
and  should  benefit  from  machine  assistance  to  record  and 
perform  the  detailed  steps) 


Within  this  methodology  reuse  may  occur  at  two  levels: 


■  Reuse  at  the  specification  level  -  our  specification 
language  comprises  a  small  set  of  powerful 
constructs  which  are  used  in  stylistically  recurring 
ways  in  specifying  a  broad  range  of  tasks  Reuse  also 
occurs  when  a  specification  is  modified,  either  to  take 
into  account  desired  changes  inspired  by  feedback 
from  the  implementation,  or  to  adapt  that  existing 
specification  to  a  similar  task. 


-  Reuse  at  the  development  level  -  when  instances  of 
the  high  level  specification  constructs  have  to  be 
transformed  into  efficient  (implementation) 
constructs:  stylistically  similar  uses  of  such  constructs 
give  rise  to  the  same  range  of  issues  in  selecting  an 
appropriate  implementation  and  in  application  of 
transformations  to  map  them  into  their 
implementations  Reuse  also  occurs  when  a  modified 
specification  has  to  be  redeveloped  into  an 
implementation,  or  altered  requirements  for  efficiency 
permute  the  various  efficiency  tradeoffs  and  so  would 
inspire  different  choices  during  the  development  of  an 
implementation  of  the  same  specification  ■  m  both 
cases  reuse  of  some  of  the  original  development  may 
take  place 


We  stress  the  importance  of  performing  modification  end 
maintenance  on  the  specification,  and  then  redeveloping  the 
implementation  from  that,  as  opposed  to  tinkering  with  the 
implementation  directly 


Reuse  arising  from  modification  of  a  specification  and  its 
subsequent  reimplementation  comprise  those  aspects  of  reuse 
with  which  we  have  had  the  least  experience,  and  form  an  area  of 
research  we  intend  to  pursue  in  the  near  future  -  see  the 
companion  paper  by  Balzer  for  details  in  this  regard.  The  other 
forms  of  reuse  -  that  is.  recurnng  themes  in  using  high  level 
specification  constructs  and  in  transforming  them  into 
implementations  -  comprise  the  focus  of  this  paper  We  report  on 
the  achievements  we  have  made  in  these  issues,  i.e..  what  are  the 
features  of  our  specification  language  that  support  reuse  at  the 
conceptual  level,  and  what  are  the  techniques  we  have 
accumulated  to  convert  such  specifications  into  implementations. 


2.  SPECIFICATION  LANGUAGE 

Our  specification  language.  Gist,  supports  the  description  of  the 
behaviour  required  of  a  process  The  motivating  source  of  Gist's 
capabilities  is  the  power  of  natural  language  descriptions:  Gist 
attempts  to  provide  constructs  to  capture  this  power  in  a  formal 
language.  Briefly,  these  capabilities  are  as  follows: 


■a  relational  and  associative  model  ol  data  which 
captures  the  logical  structure  without  imposing  an 
access  regime. 


■  information  derivation:  which  allows  tor  global 
declarations  describing  relationships  among  data. 


■  historical  reference:  the  ability  to  refer  to  past  process 
states. 


■  constraints:  restrictions  on  acceptable  system 
behaviour  in  the  form  of  global  declarations. 


■  demons:  asynchronous  processes  responding  to 
defined  stimuli,  and 


■  closed  system  specification :  the  ability  to  implicitly 
describe  the  behaviour  of  a  portion  of  some  larger 
system  by  describing  the  behaviour  required  of  the 
whole  system  and  the  interface  between  that  portion 
and  the  remainder. 


The  primary  design  goal  behind  Gist  is  to  minimize  the  gap 
between  informal  conceptualization  and  formal  specification  This 
enables  us  to  formally  capture  as  much  as  possible  of  the 
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development  process  particularly  the  early  stages  which  would 
otherwise  have  to  be  performed  entirely  within  the  heads  of 
designers  going  unrecorded  and  unassisted  by  machine  tools 
Gist  specifications  are  free  of  implementation  concerns  such  as 
efficiency  data  representation  and  algorithms  instead  their 
emphasis  is  on  describing  required  behaviour.  Gist  s  capabilities 
support  this  descriptive  (as  opposed  to  prescriptive)  style.  Gist 
specifications  tend  to  localize  the  expression  of  features  of  the 
required  behaviour  (as  opposed  to  implementations,  which 
achieve  optimality  by  spreading  information  and  control 
throughout  the  program  in  order  to  share  data  and  activity) 
These  aspects  combine  to  make  Gist  supportive  of  both  initial 
specification  and  also  of  later  modifications  to  the  specification 
When  modification  takes  the  form  of  adding  further  detail,  the 
existing  specification  tends  to  be  "robust"  in  the  sense  that  it 
should  require  little  or  no  change  when  adaitions  do  force  some 
change  or  when  the  modification  is  itself  a  change  (to  the  existing 
specification),  the  descriptive  and  localized  aspects  make  it  easy 
to  identity  the  impact  of  the  modifications  on  the  specification,  and 
easy  to  perform  the  appropriate  adjustments  In  contrast,  a  less 
expressive  specification  language  would  force  the  mental 
conversion  of  changes  at  the  conceptual  level  into  changes  at  a 
lower  more  implementation-oriented,  level,  with  the  dual 
disadvantages  of  being  harder  (more  mental  effort,  less 
opportunity  for  machine  support  -  hence  more  error  prone)  and 
failing  to  record  some  of  the  development  process  (less 
documentation  hence  less  comprehensible,  and  less  of  a  basis 
for  supporting  future  change) 

3.  DEVELOPMENT  OF  IMPLEMENTATION 

Development  of  an  implementation  from  a  Gist  specification 
necessitates  the  elimination  of  uses  of  Gist's  high-level  constructs, 
since  their  success  in  the  realm  of  specification  is  at  the  expense 
of  freedom  from  concerns  such  as  efficiency  data  representations 
and  algorithms  Program  transformation  is  the  means  by  which 
we  perform  such  development 

We  prefer  to  seek  transformations  that  deal  at  once  with  whole 
instances  of  these  constructs,  as  opposed  to  unfolding  instances 
into  lower  level  primitives  In  adopting  this  approach  we  abandon 
the  hope  for  a  small  set  of  simple  transformations,  but  retain  the 
advantage  of  dealing  with  the  constructs  at  as  high  a  level  as 
possible 

For  each  type  of  construct,  our  research  has  been  aimed  at 
accumulating: 

-  iiroiementai'or  options  commonly  available  options 
tor  converting  an  instance  of  that  construct  into  a 
more  efficient  expression  of  the  same  behaviour 
typically  in  terms  of  lower  level  constructs 

■  seectior  criteria  for  selecting  among  several 
implementation  options  applicable  to  the  same 
instance  and 

-  mappings  to  achieve  the  implementation  options  via 
sequences  of  equivalence  preserving  transformations 
Eg  a  (historical)  reference  to  the  time-ordered 
sequence  of  objects  to  satisfy  some  predicate  may  be 
mapped  into  a  data  structure  that  explicitly  stores  that 
sequence  code  to  append  obiects  to  that  sequence 
as  they  begin  to  satisfy  the  predicate  and  code  to 
replace  the  historical  reference  with  a  simple  retrieval 
from  the  data  structure 


Our  experience  on  small  examples  has  shown  that  these  are  of 
recurring  use  in  the  development  process  Samples  of  our 
findings  serve  to  illustrate  both  the  features  of  Gist  and  the 
transformational  techniques  that  we  have  accumulated  to  deal 
with  them. 


4.  AN  EXAMPLE  DOMAIN 

In  the  next  section  we  will  use  examples  drawn  from  the  domain 
of  a  single  problem  to  illustrate  our  approach  The  problem  we 
choose  is  a  routing  system  for  distributing  packages  into 
destination  bins  This  problem  was  constructed  by 
representatives  of  the  process  control  industry  to  be  typical  of 
their  real-world  applications.  Hommel  s  study  of  various 
programming  methodologies  used  this  problem  as  the 
comparative  example  [Hommel  60}. 

The  figure  below  illustrates  the  routing  network  At  the  top.  a 
source  station  feeds  packages  one  at  a  time  into  the  network, 
which  is  a  binary  tree  consisting  of  switches  connected  by  pipes. 
The  terminal  nodes  of  the  binary  tree  are  the  destination  bins 
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Figu re  4- 1 :  The  package  router 

When  a  package  arrives  at  the  source  station,  its  intended 
destination  (one  of  the  bins)  is  determined  The  package  is  then 
released  Into  the  pipe  leading  from  the  source  station.  For  a 
package  to  reach  its  designated  destination  bin.  the  switches  in 
the  network  must  be  set  to  direct  the  package  through  the  network 
and  into  the  correct  bin. 

Packages  move  through  the  network  by  gravity  (working  against 
friction)  and  so  steady  movement  of  packages  cannot  be 
guaranteed  they  may  "bunch  up"  within  the  network  end  thus 
make  it  impossible  to  set  a  switch  properly  between  the  passage  of 
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two  such  bunched  packages  (a  switch  cannot  be  set  when  there  is 
a  package  or  packages  in  the  switch  for  fear  of  damaging  such 
packages)  If  a  new  package's  destination  differs  from  that  of  the 
immediately  preceding  package,  its  release  from  the  source 
station  is  delayed  a  (precalculated)  fixed  length  of  time  (to  reduce 
the  chance  of  bunching).  In  spite  of  such  precautions,  packages 
may  Still  bunch  up  and  become  misrouted.  ending  up  in  the  wrong 
bin:  the  package  router  is  to  signal  such  an  event 

Only  a  limited  amount  of  information  is  available  to  the  package 
router  to  effect  its  desired  behaviour.  At  the  time  of  arrival  at  the 
source  station  but  not  thereafter,  the  destination  of  a  package  may 
be  determined.  The  only  means  of  determining  the  locations  of 
packages  within  the  network  is  a  group  of  sensors  (placed  on  the 
entries  and  exits  of  switches  and  on  the  entries  of  bins):  these 
sensors  detect  the  passage  of  packages  but  are  unable  to 
determine  their  identity.  (The  sensors  are  able  to  recognize  the 
passage  of  individual  packages,  regardless  of  bunching). 


5.  Gist’s  constructs 

In  this  section  Gist’s  major  constructs  are  considered  in  turn, 
and  for  each  we 

•  informally  describe  the  semantics  of  the  construct, 
with  illustrations  from  the  package  router  domain. 

-describe  the  freedoms  the  construct  provides  for 
specification, 


discuss  how  the  construct  supports  the  expression  of 
changed  versions  of  a  specification  when 
incorporating  modifications.  hypothetical 
modifications  to  the  package  router  serve  as 
illustrations,  and 
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briefly  describe  some  alternative  mappings  for  the 
construct,  together  with  criteria  for  choosing  among 
these  alternatives. 


5.1 .  Relational  and  associative  model  of  information 
We  begin  the  discussion  of  Gist  s  major  features  by  focusing  on 
its  underlying  data  model  Information  in  Gist  is  modeled  simply  by 
typed  objects  and  relations  among  them 

The  package  router  domain  involves  oo/ecrs  of  fype 
peonage,  ob/ects  of  type  switcn.  etc  Type  hierarchies 
are  possible .  for  example,  a  switch  or  a  bin  might  more 
generally  be  considered  a  location 

Relations  among  these  objects  model  information  about  this 
domain. 

The  structure  of  the  network  is  modeled  by  relations 
between  locations  ■  i.e..  the  connection  between 
source  and  first  pipe,  the  connection  between  that  first 
pipe  and  the  switch  to  which  it  leads,  etc.,  will  all  be 
modeled  by  relations  between  those  ob/ects  The 
position  of  a  package  is  modeled  by  a  relation  between 
that  package  and  its  location:  the  setting  of  a  switch 
(i.e..  the  outlet  pipe  into  which  the  switch  is  currently 
directing  packages)  is  modeled  by  a  relation  between 
switch  and  pipe 

The  collection  of  objects  and  relations  at  any  time  during  the 
interpretation  of  a  specification  comprises  what  we  call  a  "state" 
Change  m  the  domain  is  modeled  by  the  creation  and  destruction 
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of  objects  and  by  the  insertion  and  deletion  of  relations.  Each 
change  is  a  transition  from  the  current  state  into  a  new  state 
Multiple  changes  may  occur  simultaneously  in  a  single  transition 
from  one  state  to  the  next. 

The  arrival  of  a  package  at  the  source  is  modeled  by 
inserting  the  position  relation  to  hold  between  that 
package  and  the  source  location. 

Altering  the  setting  of  a  switch  is  modeled  by 
changing  the  switch-setting  relation,  i.e.,  deleting  the 
relationship  between  switch  and  old  setting,  and 
inserting  the  relationship  between  switch  and  new 
setting. 

Simultaneous  movement  of  two  packages  is 
modeled  by  changing  their  position  relations  in  the 
same  transition. 


5.1.1.  Specification  freedom 

The  relational  model  of  information  permits  the  specifier  to  use 
a  descriptive  reference  to  an  object  to  refer  to  that  object. 

The  bin  that  is  the  destination  of  this  package. 

The  pipe  into  which  this  switch  is  set  to  direct 
packages. 

The  relational  data  model  is  a  very  general  data  representation. 
The  specifier  need  not  be  concerned  about  data  access  paths,  for 
instance,  because  any  description  of  an  object  may  be  used  as  a 
reference  to  that  object  Relations  may  be  used  in  descriptions  of 
any  of  the  objects  that  participate  in  the  relationships  In  data 
base  terminology,  this  means  that  the  relationships  are  fully 
associative  (or.  equivalently,  that  the  data  base  is  fully  inverted) 

The  position  relation  (between  package  and 
location I  may  be  used  in  describing  a  locator  "The 
location  that  is  the  position  of  this  package’  and  in 
describing  a  package  "The  packagetsl  whose 
position  is  this  location ". 

Concern  about  the  statistical  distribution  of  these  operations  is 
unnecessary  The  implementation  process  selects  particular 
physical  representations  for  information  that  are  appropriate  for 
anticipated  patterns  of  data  storage  and  access 

5.1.2.  Specification  reuse 

The  generality  of  the  relational  model  and  the  freedom  from 
representation  concerns  that  it  provides  facilitate  the  expression 
of  changed  specifications. 

A  refinement  to  the  router  to  check  that  packages 
have  sufficient  postage  stamps  to  pay  for  delivery  to 
then  respective  destinations  involves  extra  information 
-  stamp  values  on  packages,  and  required  stamp 
values  for  destinations.  Modeling  this  extra  information 
is  achieved  by  defining  a  new  type,  stamp  values,  and 
additional  relationships,  between  packages  and  stamp 
values  and  between  destinations  and  required  stamp 
values 


5.1.3.  Mappings 

The  most  general  solution  to  implementing  information  storage 
is  to  support  an  associative  relational  data-base  and  leave  the 
specification's  insertions  and  retrievals  of  information  unchanged. 
In  most  cases  however,  a  specification  does  not  indiscriminately 
insert  or  retrieve  data:  rather,  it  displays  predictable  data  access 
patterns  These  can  be  mapped  into  appropriate  data  structures 


i 
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(arrays,  hash  tables,  etc ..)  to  conserve  space  and  time 

If  the  relation  that  models  the  destination  of  a 
package  h  e  ,  a  'elation  betweer  the  package  and  the 
Dm  that  is  its  destination)  is  accessed  in  one  direction 
only  0)  asking  tor  the  om  that  is  the  destination  ot  a 
package  then  the  destination  information  could  be 
stored  as  a  field  ot  a  record  structure  ot  information 
associated  with  each  package 

Concerns  tor  efficiency  of  time  and  space  dictate  the  selection 
of  data  structures.  Probabilistic  expectations  of  frequency  of  use 
are  not  explicitly  described  in  Gist  specifications  Clearly,  for 
implementation  purposes  such  information  will  oe  of  importance 
in  selection 

it  snouid  be  noted  tnat  many  o'  the  issues  relating  to  the 
relational  data  model  are  similar  to  those  investigated  by  the  SETL 
group  [Dewar  et  a:  79]  [Schonberg  Scnwartz  &  Sharir  81]  and  by 
Rovner  [flovner  73]  low  [Low  76].  and  Barstow  [Barstow  79] 


5.2.  Information  derivation 

Often  it  is  convenient  to  make  use  of  a  relationship  that  Is 
derived  from  other  relationships  Within  Gist  the  derivation  of 
such  a  relationship  may  be  declared  once  and  for  all  and  serves 
to  denote  all  the  maintenance  necessary  to  preserve  the  invariant 
between  the  derived  relation  and  the  relations  upon  which  it 
depends 

£  switch  may  oe  said  tc  De  empty  r  there  is  no 
package  wnose  location  is  tne  switch  tnence  empty'  is 
a  unary  relation) 

A  location  may  oe  said  tc  oe  beiow  a  second 
location  if  it  is  immediately  Deiow  that  second  location. 

Or  is  immediately  Deiow  some  third  location  that  is  m 
turn  'below  the  second  location  I i.e..  transitive  closure 
of  immediately  below) 

5.2.1 .  Specification  freedom 

The  specifications!  power  of  this  construct  comes  from  being 
able  to  state  a  derivation  in  a  single  place  (i.e  this  construct 
exhibits  the  quality  of  "locality")  and  then  make  use  of  the  denved 
information  throughout  the  specification.  As  with  explicitly 
inserted  relations,  data  access  is  fully  associative 

The  derived  'below'  relation  may  be  accessed  in 
either  direction,  i.e.  given  a  location,  the  relation  may 
De  accessed  to  find  either  the  locations  which  are 
below'  that  location,  or  the  locations  which  that 
location  is  below . 

5.2.2.  Specification  reuse 

Derived  relations  provide  robustness  in  the  face  of  specification 
change  both  because  of  their  localised  nature,  and  because  they 
are  defined  in  terms  of  the  information  upon  which  they  depend 
(i.e  .  have  the  "descriptive"  quality). 

Should  the  structure  of  the  package  router  network 
be  extended  by  addition  of  more  pipes,  switches  and 
bins,  the  definition  ot  the  derived  relations  empty’  and 
'below  ’  will  continue  to  be  valid 

On  the  occasions  when  the  definitions  of  derived  relations  must 
be  modified,  the  localised  nature  of  their  definitions  eases  the  task 
of  correctly  making  such  modifications 


5.2.3.  Mappings 

Since  no  corresponding  construct  is  likely  to  be  available  in  any 
implementation  language  we  might  choose  we  must  map  the 
derivation  into  explicit  data  structures  and  mechanisms  to  support 
all  the  uses  of  that  information  scattered  throughout  tne  program 
We  have  a  wide  range  of  choices  as  to  how  we  might  do  this 
mapping 

At  one  extreme,  we  might  simply  unfold  the  derivation  at  all  the 
places  where  a  reference  to  the  relation  is  made  Having  done 
this  we  may  completely  discard  the  relation  and  its  derivation 

Wherever  tne  specification  makes  reference  to  the 
empty  relation  on  a  switch,  unfold  the  definition  of 
empty  .  to  leave  in  its  place  an  explicit  search  through 
an  the  packages  to  determine  whether  any  of  them  are 
located  at  the  switch. 

This  approach  is  analogous  to  backward  inference,  where 
computation  is  performed  on  demand  and  at  the  site  ot  the  need 

At  the  other  extreme  we  might  retain  the  relation,  but  distribute 
throughout  the  program  the  code  necessary  to  explicitly  maintain 
the  invariant  between  the  derived  information  and  the  information 
upon  which  it  depends. 

To  maintain  the  derived  relation  of  switch  empty', 
introduce  explicit  storage  (in  the  form  ot  a  non-derived 
relation)  to  represent  this  information,  and  introduce 
the  appropriate  maintenance  code  everywhere  in  the 
specification  that  the  locations  of  packages  might 
change  (more  precisely,  at  the  places  where  a  package 
may  become  located  at.  or  cease  being  located  at. 
switches) 

This  approach  is  analogous  to  forward  inference,  where 
computation  is  performed  whenever  a  modification  to  a  relevant 
predicate  occurs  and  at  the  site  of  the  change.  There  are  two 
separate  capabilities  required  by  this  mapping: 

1 .  determining  all  those  locations  in  the  specification  at 
which  the  value  of  a  derived  relation  could  oossibly  be 
changed. and 

2.  inserting  code  to  do  the  recalculation  at  those 
locations 

The  latter  capability  can  be  achieved  by  either  recomputing  the 
defined  relation  from  scratch,  or  incrementally  changing  its 
present  value 

To  maintain  the  seauence  of  packages  in  a  pipe, 
when  a  package  enters  the  pipe,  concatenate  that 
package  onto  the  end  of  the  maintained  seauence. 
when  a  package  exits,  remove  the  package  from  the 
front  ot  the  maintained  sequence 

This  is  an  example  of  a  general  technique  we  call  "incremental 
maintenance",  and  is  derived  from  the  work  of  other  researchers 
in  set-theoretic  settings,  particularly  [Paige  &  Schwartz  77],  who 
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Many  of  the  Artificial  Intelligence  programming  languages  do  provide  facilities 
lor  implementing  derived  relations  m  terms  ot  inference  processes  For  exsmpfe.  a 
implementation  of  derived  relations  might  be  provided  in  CONNIVES  [McDermott  t 
Suwman  74]  m  terms  of  IF  ADDED  of  IF -NEEDED  methods  However.  Al 
programming  languages  in  which  these  facilities  are  present  typically  do  not 
provide  for  the  efficient  execution  one  would  desire  tor  an  opbmiisd 
implementation,  nor  do  these  facilities  provide  preceety  the  semaribcs  desired 
without  the  inclusion  of  saMactory  'truth  maintenance'  eapabiliMe.  [Doyle  79). 
[London  7B) 
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call  the  techniaue  "formal  differentiation'  ,  and  [Earley  75].  who 
calls  it  "iterator  inversion1 

Unfolding  a  derived  relation  results  m  rederivation  at  points  of 
use:  maintaining  it  results  in  rederivation  (incrementally  or 
otherwise)  at  points  of  change  It  is  permissible  to  do  the 
computation  for  maintaining  the  relation  at  other  points,  but  it 
must  have  its  correct  value  by  the  time  is  used 

The  choices  among  the  implementation  alternatives  suggest 
alternatives  between  storage  and  computation  in  the  resulting 
program.  Completely  unfolding  the  derivation  is  tending  towards 
complex  recalculation  with  a  minimum  of  stored  data. 
Maintenance  simplifies  retrievals  at  the  expense  of  the 
maintenance  operations  and  the  extra  storage  to  hold  the 
maintained  information 


5.3.  Historical  reference 

Historical  reference  in  Gist  specifications  provides  the  ability  to 
extract  information  from  any  preceding  state  in  the  computation 
history. 

Has  this  package  ever  been  at  that  switch ?. 

What  was  the  most  recent  package  to  have  been  in 
this  switch?. 

Was  the  bin  empty  when  the  package  entered  the 
network ? 

Note  that  the  past  can  only  be  queried,  not  changed. 

5.3.1 .  Specification  freedom 
Historical  reference  allows  the  specifier  to  easily  and 
unambiguously  describe  whar  information  is  needed  from  earlier 
states  without  concern  for  the  details  of  how  it  might  be  made 
available  (i.e..  like  derived  information,  this  construct  has  the 
"descriptive"  quality)  Reference  to  the  past  has  been  studied  in 
the  database  world,  where  the  freedom  has  been  called  "memory 
independence"  and  temporal  logic  has  been  applied  to  formally 
investigate  the  matter  (see  e  g..  [Sernadas  80])  Both  constructs 
may  be  mixed  using  derived  relations  in  expressing  a  historical 
reference,  and  using  historical  reference  in  defining  a  derived 
relation 

Historical  reference  "Was  this  switch  ever 
empty 


5.3.3.  Mappings 

Two  generally  applicable  methods  exist  for  mapping  historical 
reference  into  a  reasonable  implementation  These  are: 

1 .  save  the  information  desired  in  the  earlier  state,  then 
modify  the  historical  reference  to  extract  it  from  the 
saved  information,  or 

2  modify  the  historical  reference  to  redenve  the  desired 
information  from  the  current  state. 

To  use  the  first  method,  it  is  necessary  to  introduce  and  maintain 
auxiliary  data  structures  to  store  information  that  might  be 
referenced  in  a  later  state,  and  modify  the  historical  references  to 
extract  the  desired  information  from  those  introduced  structures 
when  needed  The  desire  for  economy  of  storage  in  an 
implementation  encourages  the  implementor  to  determine  just 
what  information  need  be  preserved  see*  a  compact 
representation  facilitating  both  storage  and  retrieval  and  discard 
the  information  once  it  is  no  longer  useful 

To  be  prepared  to  answer  the  Query  "what  was  the 
destination  of  the  last  package  to  have  passed  through 
this  switch?"  we  could  choose  to  remember  the  time- 
ordered  seguence  of  packages  to  nave  been  in  the 
switch,  or  more  efficiently,  only  the  destination  o'  me 
immediately  preceding  package  This  latter  case  woula 
reouire  storage  space  tor  the  identity  of  only  a  single 
destination  bin.  upon  arrival  of  a  new  package,  the 
identity  of  its  destination  would  be  remembered  in  that 
space,  overwriting  the  old  information 

The  alternative  method  for  implementing  historical  reference  is 
to  rederive  the  desired  information  in  terms  of  information 
available  in  the  current  state  (without  having  to  retain  extra 
information  from  past  states). 

The  identity  of  the  previous  package  to  have  been  at 
this  switch  might  be  derived  by  determining  which 
package  in  the  network  is  closest  to  and  oownnill  from 
the  switch. 

We  suspect  that  rederivation  is  rarely  an  available  option:  the 
information  desired  is  often  not  derivable  from  current  available 
information.  When  both  options  are  possible  they  present  the 
classic  store/recompute  tradeoffs.  An  implementor  must  compare 
the  cost  of  the  derivation  with  the  cost  of  storage  and 
maintenance  of  redundant  information  to  permit  simple  access 


Derived  relation  definition  ” The  sequence  of 
packages  to  have  been  located  at  the  source,  in  their 
order  of  arrival  there  " 

This  exemplifies  one  of  Gist's  strengths  the  "orthogonality"  of  the 
constructs,  i.e..  they  may  be  successfully  used  in  combination 

5.3.2.  Specification  reuse 

Historical  reference,  like  derived  information  provides 
robustness  as  a  consequence  of  its  descriptive  nature,  in  this 
case,  robustness  in  the  face  of  modifications  that  result  in 
changed  histones 

Should  the  topology  of  the  network  be  modified,  say 
to  feed  the  output  of  several  pipes  into  the  same  bin. 
then  the  descriptive  historical  reference  " The 
sequence  of  packages  to  have  reached  the  bin  in  their 
order  of  arrival"  will  continue  to  be  valid 


5.3.4.  Idiomatic  uses  of  historical  reference 
Certain  patterns  of  historical  reference  recur  frequently  in  Gist 
specifications.  For  example,  evaluating  < predicate >  asof  <event>. 
or  < expression >  asof  <event>  (of  which  What  was  the  setting  of  the 
switch  at  the  time  the  package  entered  the  network ?  is  an 
example).  For  an  idiom  like  this  we  can  construct  special  purpose 
mappings.2  reducing  the  effort  that  would  be  required  during 
implementation  development  if  a  general  purpose  mapping 
technique  was  applied.  A  general- purpose  mapping  technique 
would  require  application  of  further  simplifications  to  tailor  the 
result  for  the  special  case. 


idiom  a  mapfMd  into  an  explicit  rotation  between  the  objects  that 
paramoteme  the  event  and  the  <predicate>  /  <expression>,  together  with  code  to 
maintain  the  relation,  namely  to  mean  the  relation  whenever  the  event  occur*  and 
the  <predicate>  holds  /  there  exists  an  object  denoted  by  the  <expression> 


Otter  idioms  that  we  deal  with  include: 


and  as  we  shall  see.  demons  too,  provide  freedoms  related  to 
control. 


•  the  latest  object  to  satisfy  a  given  predicate. 

-  the  sequence  of  objects  ordered  by  their  time  of 
creation  or  the  time  at  which  they  satisfied  a  given 
predicate 

-  did  event .  take  place  before  event2? 


5.4.  Nondeterminiem  and  constraints 

Nondeterminism  within  Gist  occurs  in  two  ways'  When  use  is 
made  of  a  descriptive  reference  that  denotes  more  than  one 
object. 

Set  the  switch  to  one  of  the  switch  outlets, 

or  when  some  specifically  nondeterministic  control  structure  is 
used 

Choose  Detween  "Set  switch"  and  “Release 
package" 

In  terms  of  the  behaviour  that  a  Gist  specification  denotes, 
nondeterminism  gives  rise  to  a  asl  of  behaviours:  an  implementor 
is  tree  to  select  any  (non-empty!)  subset3  of  those  behaviours  as 
the  ones  his  implementation  will  satisfy. 

The  activity  of  setting  switches  is  described 
nondeterministically  by  stating  that  at  random  times 
random  switches  set  themselves  to  a  random  one  of 
their  outlet  pipes. 

Constraints  within  Gist  provide  a  means  of  stating  integrity 
conditions  that  must  always  remain  satisfied. 

Packages  in  some  location  cannot  overtake  one 
another  tie.,  a  package  that  entered  some  location 
later  than  another  package  cannot  leave  that  location 
before  that  other  package). 

A  switch  must  be  empty  in  order  to  change  its 
setting 

A  package  must  never  reach  a  wrong  bin  (i.e.,  some 
bin  other  than  its  destination I4 

Within  Gist,  constraints  are  more  than  merely  redundant  checks 
that  the  specification  always  generates  valid  behaviours; 
constraints  serve  to  rule  out  those  behaviours  that  would  be 
invalid 

The  nondeterminism  of  switch  setting,  in 
conjunction  with  the  constraint  on  packages  reaching 
correct  bins,  denotes  only  behaviours  that  route  the 
packages  to  the  proper  destination  bins 

5.4.1 .  Specification  freedom 

The  constructs  described  in  previous  sections  provided 
freedoms  related  to  information:  nondeterminism  and  constraints. 

3l  t .  man  my  t»  Dwwwoun  Mncted  by  the  wbeffletton  not  dKeilyod  by  the 
imc— mentation  Conversely  however,  *ny  behaviour  depliyeb  by  the 
implementation  must  be  one  oi  the  behaviours  denoted  by  #»  speeiheatien 

4 Although  true  would  be  e  desirable  constraint  to  mtpoee  on  the  package  router, 
a  would  lender  an  enoiementabon  mwoaaibte  because  e l  the  conditions  within 
whKh  die  router  mechanism  has  to  operate,  most  notably  the  vagaries  o(  the 
movement  oi  Baeeages.  end  die  limits  on  swdeh  setting  It  makes  a  nice  sssmpie. 


Where  there  are  several  equally  acceptable  alternatives  in  the 
resolution  of  a  data  reference  or  a  control  structure  choice, 
nondeterminism  makes  it  easy  to  express  them  all  Where  there 
are  integrity  conditions  that  must  be  satisfied  constraints  provide 
a  concise  (i.e..  localised)  means  of  stating  them  Such  integrity 
conditions  may  serve  as  descriptions  of  the  environment  in  which 
the  portion  to  be  implemented  is  to  operate  and  so  provide 
information  about  the  environment  upon  which  the  implementor 
may  rely  (e.g.,  the  nonovertaking  of  packages  within  locations  is  a 
property  of  the  physical  routing  mechanism).  Other  integrity 
conditions  serve  as  requirements  on  the  behaviour  of  the  r 
system,  implying  that  the  implementor  must  implement  his  on 
in  such  a  manner  that  it  will  operate  with  the  environment  to 
satisfy  those  conditions  (e  g.,  that  the  switch  be  empty  in  i  j,  to 
change  its  setting). 

The  conjunction  of  nondeterminism  and  constraints  pi  <rs 
be  an  extremely  powerful  specification  technique:  a  specif  i 
denotes  those  and  only  those  behaviours  that  do  not  violate 
constraints.  In  contrast,  an  implementation  is  characterized  by 
the  cunning  encoding  of  its  components  to  interact  in  ways 
guaranteed  to  result  in  only  valid  behaviours 

5.4.2.  Specification  reuse 

Constraints  provide  robustness  in  the  face  of  specification 
change  because  by  their  very  nature  they  guarantee  that  all  the 
behaviours  (ok)  or  new)  denoted  by  a  changed  specification  must 
abide  by  all  the  constraints  that  remain  in.  or  have  been  added  to. 
the  specification. 

The  constrain!  that  a  switch  be  empty  in  order  to 
change  its  setting  assures  us  that  no  matter  how  the 
topology  of  the  network  might  be  modified,  we  may 
remain  assured  that  no  new  behaviour  will  result  in 
which  a  switch  setting  changes  while  some  package  is 
present  in  that  switch. 

Constraints  themselves  are  readily  modified  to  reflect  changing 
criteria 

To  further  restrict  when  a  switch  setting  may  be 
changed,  say  to  only  those  occasions  when  that  switch 
and  the  pipe  that  leads  into  it  are  both  empty,  we 
simply  modify  the  constraint  accordingly  ■  a  single 
modification  at  only  one  place  in  the  specification 

5.4.3.  Mapping  away  constraints  and  nondeterminism 

A  general  mapping  technique  to  eliminate  constraints  is  to  make 
each  nondeterministic  activity  into  a  choice  point,  and  to  unfold 
global  constraints  so  as  to  provide  tests  at  all  points  in  the 
program  where  the  constraint  might  possibly  be  violated  When  a 
violation  is  detected,  a  "failure"  results  this  causes  backtracking 
to  the  most  recent  choice  point  with  an  alternative  choice 

To  place  8  o ueens  on  a  cness  board  unde-  the 
constraint  that  no  oueen  may  attack  any  other  gueen 
simultaneously  place  alt  the  o ueens  on  the  board  (6*e 
nondeterministic  choices'),  and  after  doing  sc  check 
to  see  whether  the  no-capture  constraint  is  violated  ■  i' 
so.  try  the  next  choice  of  placements  l Note  that  this  is 
a  most  inefficient  mapping  ) 

This  mapping  is  similar  to  the  maintenance  mapping  for  derived 
relations,  two  separate  processes  are  required  to  implement  the 
mapping: 
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1 .  determining  all  locations  in  the  specification  at  which 
the  constraint  might  be  violated  (similar  to 
determining  all  locations  where  the  value  of  a  derived 
relation  could  change),  and 

2  inserting  at  those  points,  code  to  do  the  checks  and 
backtracking  (whereas  in  the  case  of  derived 
relations,  the  code  inserted  would  have  the  purpose 
of  updating  the  stored  value  of  the  relation) 

The  second  capability  mentioned  above  as  required  for 
mapping  constraints  and  nondeterminism  implements  the 
backtracking  control  mechanism.  Our  research  suggests  that  it  is 
possible  to  intermix  Gist  s  nondeterminism  and  constraints  with 
explicit  backtracking,  permitting  the  incremental  mapping  of 
individual  nondeterministic  choice  points,  and  of  the  constraints 
that  impinge  upon  them  (as  opposed  to  having  to  simultaneously 
map  away  an  the  nondeterminism  and  constraints  at  once).  The 
task  of  building  the  backtracking  mechanism  itself  is  trivial  if  our 
intended  target  language  supports  backtracking  (as  does,  for 
example.  PROLOG  [Clocksin  &  Mellish  81]). 

Backtracking,  however,  presupposes  the  ability  to  undo  actions 
that  have  been  executed  since  the  last  choice  point  Since  this  is 
often  not  possible  strict  backtracking  is  not  always  an  option  for 
mapping  to  an  implementation  of  nondeterminism 

in  controlling  trie  switches  in  the  routing  network,  we 
might  be  constrained  to  ensure  that  tne  packages  do 
no:  reach  wrong  destinations  Backtracking 
presupposes  that  we  have  the  ability  to  return  the 
p  acrages  to  tne  switching  points  at  re-  an  error  is 
detected  and  men  send  them  m  different  directions. 
Obviously,  in  the  case  of  a  package  router  whose 
package  movement  mechanism  is  no:  under  our 
control,  this  is  not  an  available  option. 

An  alternative  technique  to  mapping  nondeterminism  into 
backtracking  is  a  "predictive'  solution  Here  the  constraints  are 
unfolded  but  into  "point"  constraints  rather  than  into  calls  on  a 
backtracking  failure  mechanism  These  point  constraints  are  then 
pushed  back  to  be  incorporated  into  the  choice  points  becoming 
filters  that  propose  only  those  choices  that  guarantee  no 
constraints  will  be  violated  "Pushing"  a  point  constraint 
backwards  over  a  statement  is  a  matter  of  reformulating  the 
constraint  into  the  weakest  precondition  to  that  statement  that 
guarantees  execution  of  the  statement  will  not  violate  the 
constraint  When  the  constraint  is  "pushed"  all  the  way  back  to  a 
choice  point,  it  is  incorporated  as  a  filter  on  the  choices 

When  a  switch  becomes  empty,  choose  to  set  it  in 
the  direction  that  leads  to  the  destination  of  the  next 
package  approaching  the  switch. 

Compromise  between  these  two  extremes  is  possible:  we  may 
employ  a  backtracking  algorithm,  but  push  some  (though  not  all) 
of  the  unfolded  constraint(s)  into  the  choice  generators 

In  the  8-oueens  problem,  split  the  nondeterminism 
into  several  successive  choices  (place  the  first  Queen, 
place  the  second  Queen  and  check  for  capture  etc.), 
and  incorporate  some  of  the  no-capture  constraint  into 
the  placement  (by  not  attempting  to  place  a 
subseauent  Queen  on  a  row  already  occupied  by  a 
Queen)  See  [Balier  81)  for  a  detailed  development 
illustrating  this 


The  choice  between  a  backtracking  implementation  and  a 
predictive  implementation  is  determined  very  much  by  the  nature 
of  the  domain  of  the  specification  The  capabilities  of.  and  the 
control  we  have  of.  the  effectors5  (if  there  are  any  in  the  system 
being  specified),  the  amount  of  information  available  for  making 
decisions,  and  the  desired  amount  of  precomputation  all  affect  the 
choice  of  algorithm.  Typically,  the  interesting  issue  is  to  develop 
the  specification  toward  an  implementation  that  embodies  an 
algorithm  to  perform  the  search  efficiently,  and  not  to  assume  that 
the  result  has  been  pre  calculated  and  make  use  of  it 


5.5.  Demons 

Demons  provide  Gist  s  mechanism  for  data  directed  invocation 
of  processes  A  demon  has  two  components  a  tngge'  and  a 
response  Whenever  a  state  change  induces  a  change  in  the 
value  of  the  trigger  predicate  from  false  to  true,  the  demon  s 
response  is  invoked 

Whenever  a  package  reaches  a  wrong  bin  (some  bin 
other  that  its  intended  destination),  send  a  signal 

5.5.1 .  Specification  freedom 

Demons  are  a  convenient  construct  for  situations  in  which  we 
wish  to  specify  the  execution  as  an  asynchronous  activity  that 
arises  from  a  particular  change  of  state  in  the  modeled 
environment  This  eliminates  the  need  to  identify  individual 
portions  of  the  specification  where  actions  might  cause  such  a 
change  and  the  need  to  insert  into  such  places  the  additional 
code  necessary  to  invoke  the  response  accordingly.  The 
specificational  power  of  the  demon  construct  is  enhanced  by  the 
power  of  Gist's  other  features,  for  example  the  triggering 
predicate  may  make  use  of  derived  information 

5.5.2.  Specification  reuse 

The  descriptive  nature  of  demons  -  i.e..  the  description  of  the 
condition  upon  which  some  activity  is  to  be  started  •-  provides  the 
robustness  Should  modifications  to  the  specification  change  the 
behaviours  that  may  occur,  the  demons  will  continue  to  be 
triggered  when  and  only  when  their  triggering  conditions  are  met 

Should  the  topology  of  the  router  network  be 
modified  so  that  several  pipes  lead  to  the  same  output 
bin  (i.e ,  the  network  is  no  longer  a  tree),  then  the 
demon  that  signals  arrivals  of  misrouted  packages  will 
continue  to  do  its  signaling  regardless  ot  which  pipe 
they  happen  to  emerge  from. 

5.5.3.  Mapping  away  demons 

Mapping  away  a  demon  involves  identifying  all  places  in  the 
program  where  a  state  change  might  cause  a  change  of  the  value 
of  the  demon  $  trigger  from  false  to  true,  and  then  inserting  code 
at  those  places  to  make  the  determination  and  perform  the 
demon's  response  when  necessary. 

t0  map  away  a  demon  which  sends  a  signal  every 
tine  a  package  reaches  a  wrong  bin.  introduce  code 
into  the  places  where  package  movement  occurs  to 
check  to  see  wnetne’  mat  package  has  moved  into  a 
bin  other  than  its  destination,  in  such  a  case  perform 
the  signalling 
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This  is  another  mapping  that  maxes  use  of  the  capability  to 
laentify  locations  in  the  specification  where  the  value  of  a 
predicate  (in  this  case  the  demon's  trigger)  might  be  affected  (in 
particular,  change  from  false  to  true).  Here  the  action  to  be  taxen 
upon  detecting  such  a  change  is  to  invoxe  the  demon  s  response. 

Demons  are  a  potent  source  of  nondeterminism  in  the 
behaviours  denoted  by  a  specification.  This  is  because  our 
semantics  for  demon  “response"  are  that  a  new  “line  of  control" 
to  perform  that  response  is  begun,  and  that  line  of  control  runs  in 
parallel  with  the  already  active  line(s)  of  control,  permitting  any 
aroitrary  interleaving  that  does  not  violate  constraints 

in  the  package  router,  specify  the  behaviour  of  a 
switch  via  a  aemor  that  has  a  random  trigger s.  ana 
whose  response  is  to  set  the  switch  to  any  of  its  outlets 
(further  nondeterminism).  Together  with  a  constraint 
to  prohibit  items  trorr  being  routed  to  incorrect 
destinations,  this  would  suffice  to  denote  oenaviours  in 
which  switches  are  set  at  the  appropriate  times  and  in 
the  appropriate  directions  to  effect  correct  routing, 
while  denoting  complete  freedom  of  switch  behaviour 
when  their  settings  are  not  crucial  to  the  routing  of  any 
packages 

Our  experience  with  both  specifying  and  mapping  this  form  of 
nondeterminism  is  somewhat  limited.  We  anticipate  that  in  many 
cases  it  will  be  preferable  to  map  this  form  of  nondetermimstic 
control  structure  while  expressed  concisely  as  demons,  rather 
than  first  to  unfold  those  demons  throughout  the  specification  and 
then  to  have  to  manage  the  resulting  disparate  instances  of 
nondeterminism.  Our  hope  is  that  control  nondeterminism 
provided  by  demons,  constrained  by -constraints  which  prune  out 
the  undesired  effects  of  arbitrary  interleaving,  will  occur  in 
commonly  occurring  styles  of  usage,  for  which  we  will  be  able  to 
build  idiomatic  mappings. 


5.6.  Closed  system  style 

For  specification  purposes  it  is  convenient  to  describe  the 
behaviour  required  of  an  entire  system,  and  to  build  that 
description  in  terms  of  information  throughout  the  system.  How 
that  entire  system  is  to  be  decomposed  into  components,  the 
restrictions  on  the  control  that  components  may  exert  over  one 
another,  and  the  access  that  components  may  have  to  each 
others  information,  may  described  separately  from  the  overall 
system  behaviour  description. 

In  the  package  router  we  describe  the  behaviour 
required  of  the  overall  system,  namely  the  routing  of 
packages  This  description  is  expressed  in  terms  of 
package  locations  and  destinations  Separately  we 
describe  how  the  system  comprises  several 
components 

-  physical  routing  mechanism  (the  binary  tree  of 
source,  pipes,  switches  and  bins). 

-  an  uncontrollable  and  unpredictable 
mechanism  to  move  packages  (gravity 
interacting  with  friction). 

■an  unpredictable  input  of  packages  at  me 
source  to  be  routed,  and 
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-  the  switch  controller  which  may  change  switch 
settings 

It  is  our  development  task  to  implement  the  switch 
controller  so  as  to  interact  with  the  other  components 
in  such  a  way  as  to  cause  the  desired  routing  of 
packages  Furthermore,  the  switch  controller  has  only 
limited  control  of.  and  access  to.  the  other 
components  A  switch  setting  may  only  be  changed 
when  it  is  empty  of  packages  The  only  occasion  upon 
which  the  controller  mechanism  may  read  the 
destination  of  a  package  is  when  that  package  is  at  the 
source  Once  released  into  the  network,  the  only 
information  available  to  the  controller  is  the  passage  of 
individual  packages  past  sensors,  and  even  then  only 
the  face  that  some  package  has  passed  is  available, 
not  even  the  identity  of  the  package 

5.6.1.  Specification  freedom 

Closed  system  description  provides  the  freedom  to  describe  the 
behaviour  required  of  the  whole  system,  and  to  give  this 
description  in  terms  of  system-wide  information.  The 
decomposition  of  the  system  into  components  is  specified 
separately  The  behaviours  of  these  components  are  thus 
implicitly  defined  to  be  those  which  in  conjunction  will  achieve  the 
required  system  wide  behaviour  while  complying  with  the 
limitations  on  control  and  information  passing  between 
components.  Maximum  freedom  is  left  to  the  developer  to  choose 
any  of  these  implicitly  defined  behaviours  for  the  components  to 
be  implemented. 

5.6.2.  Specification  reuse 

Since  system  wide  behaviour  is  specified  directly,  modifications 
to  that  behaviour  are  easy  to  incorporate  Modifications  to  the 
environment  (within  which  the  implemented  portion  resides)  may 
also  be  readily  expressed,  and  the  system-wide  specification  of 
required  behaviour  remains  unchanged 

If  the  physical  router  mechanism  is  adiusted  to  move 
packages  by  means  of  iixeo  speed  conveyc  belts  sc 
as  to  prevent  packages  from  bunching  up.  this  extra 
properly  may  simply  be  added  to  the  specification  o' 
the  environment.  The  implementor  will  then  be  able  to 
take  advantage  of  this  extra  information  m  his 
rederivation  of  an  implementation  (and  in  such  a  case 
could  guarantee  100%  correct  routing) 

Having  the  decomposition  stated  separately  from  system 
behaviour  ••  indeed,  having  it  explicitly  stated  at  all  -•  supports 
modifications  to  the  decomposition. 

It  the  sensors  throughout  the  package  router 
network  are  enhanced  to  report  not  only  the  passage  of 
a  package,  but  also  the  destination  of  the  passing 
package,  then  this  enhancement  may  be  incorporated 
into  the  specification  of  the  decomposition,  permitting 
the  implementor  of  the  router  mechanism  to  make  use 
of  the  extra  information  (which  should  result  in  $ 
reduction  in  the  amount  of  storage  space  tor  data 
required  by  the  implementation) 

5.6.3.  Mapping  away  ralianca  on  system<wide  control  and 
information 

The  general  problem  of  mapping  away  such  reliance  is  quite 
difficult.  Mostow  calls  this  aspect  of  development 
"  operationalization " .  and  has  investigated  heuristic  means  for 
dealing  with  it,  [Mostow  61]. 


For  some  simple  cases  of  reliance  on  system-wide  information, 
techniques  similar  to  those  used  for  mapping  away  historical 
references  might  prove  appropriate  •  introduce  and  maintain 
auxiliary  data  structures  to  hold  information  when  it  is  made 
available  in  order  to  be  able  to  supply  that  information  when  it  is 
needed,  or  look  for  ways  to  derive  the  required  information  from 
other  information  that  is  available. 

6.  SUMMARY  AND  FUTURE  WORK 

Gist's  combination  of  constructs  makes  for  a  good  specification 
language,  and,  we  anticipate,  will  support  reuse  at  the 
specification  level.  We  attribute  Gist's  success  to  its  purposeful 
design  -  modeled  on  the  power  of  natural  language  descriptions, 
brought  together  into  a  coherent  formal  framework. 

The  development  methodology  we  advocate  is  one  of 
transformation  of  specifications  to  obtain  implementations  The 
success  or  failure  of  this  methodology  for  supporting  reuse  rests 
upon  our  ability  to  reperform  the  transformational  development 
upon  a  modified  specification.  This  is  the  crucial  outstanding 
research  issue 

The  mappings  for  Gist  constructs  will  comprise  tne  primitive 
steps  from  which  Gist  developments  will  be  composed  and  the 
choice  criteria  between  mappings  will  form  the  basis  tor  selection 
of  appropriate  mappings.  It  has  been  recognised  that 
transformational  developments  must  be  objects  in  their  own  right 
so  that  they  may  be  applied  to  specifications  to  produce 
implementations  and  appropriately  modified  tc  be  applied  to 
modified  specifications  [Darlington  &  Feather  60]  The  language 
for  recording  such  developments  must  be  rich  enough  to  capture 
the  implementor’s  goal  structure  -  motivations  and  design 
decisions  -  [Smtzoff  80]  and  [Wile  82]  The  system  that  applies 
such  developments  must  deal  with  this  goal  structure,  methods  for 
achieving  goals,  and  selection  criteria  for  choosing  among 
competing  methods  and.  for  the  foreseeable  future  will  not  be 
fully  automatic  so  must  rely  upon  interaction  with  a  skilled 
implementor  See  [Fickas  82]  for  a  first  cut  at  such  a  system 

Acknowledgements 

This  research  was  supported  by  Defense  Advanced  Research 
Protects  Agency  contract  MDA  903  81  C  0335  Views  and 
conclusions  contained  in  this  document  are  those  of  the  author 
and  should  not  be  interpreted  as  representing  the  official  opinion 
or  policy  of  DARPA.  the  U.S  Government,  or  any  other  person  or 
agency  connected  with  them  I  would  like  to  thank  the  other 
members  (past  and  present)  of  the  ISI  Transformational 
Implementation  group:  Bob  Balzer.  Don  Cohen  Steve  Fickas.  Neil 
Goldman.  Phil  London.  Jack  Mostow.  Bill  Swartout  and  Dave  Wile. 

References 

[Balzer8i]  Balzer.  R.  "Transformational  Implementation.  An 
Example."  IEEE  Transactions  on  Software  Engineering  SE-7. 
(1).  1981.3-14 

[Barstow  79]  Barstow  D.fi  "Knowledge-Based  Program 
Construction".  Elsevier  North -Holland  1979 

(Clocksin  &  Mellish  81]  Clocksin,  W.F.  &  Mellish.  C.S.. 

Programming  in  Prolog.  Springer  Verlag,  Berlin,  1981. 

(Darlington  &  Feather  80]  Darlington.  J  ft  Feather  M  S..  "A 
transformational  approach  to  program  modification  ". 
Department  of  Computing  and  Control.  Imperial  College, 
London  Technical  Report  80/3. 1960 


[Dewar  et  al  79]  Dewar.  R.B.K..  Grand  A..  Liu.  S  ft  Schwartz.  J  T  . 
"Programming  by  refinement,  as  exemplified  by  the  SETl 
representation  sublanguage  "  ACM  Transactions  or 
Programming  Languages  and  Systems  1.(1).  1979.  27-49 

[Doyle  79]  Doyle,  J.,  "A  truth  maintenance  system  "  Artificial 
intelligence  12.  (3)  1979.  231-272 

[Earley  75)  Earley.  J.  "High  level  iterators  and  a  method  for 
automatically  designing  data  structure  representation  " 
Computer  Languages  1.  (4).  1975  321-342 

[Fickas  82]  Fickas.  S.F..  "Automating  the  transformational 
development  of  software" .  Ph.D.  thesis  University  of 
California.  Irvine.  1982 

[Hommel  80]  Hommel.  G..  Vergteich  versctuedener 

Spezifikationsverfahren  am  Beispiei  erne'  Paketverteilanlage. 
Kernforschungszentrum  Karlsruhe,  Technical  Report,  August 
1980. 

[London  78]  London,  P.,  "A  dependency-based  modelling 
mechanism  for  problem  solving,"  in  AFIPS  Conference 
Proceedings,  vol.  47,  pp.  263-274. 1978 

[Low  76]  Low,  J.R.,  interdisciplinary  Systems  Research  Volume 
16:  "Automatic  Coding:  Choice  of  Data  Structures". 
Birkhauser  Verlag.  Basel  ft  Stuttgart.  1976 

[McDermott  ft  Sussman  74]  McDermott,  D.  ft  Sussman.  G.  J..  The 
CONNIVER  reference  manual,  MIT,  Technical  Report  Memo 
259a,  1974. 

[Mostow  81]  Mostow.  D.J..  "Mechanical  transformation  of  tas* 
neuristics  into  operational  procedures"  Ph  D  thesis 
Computer  Science  Department  Carnegie-Mellon  University 
1961. 

[Paige  ft  Schwartz  77]  Paige.  R.  &  Schwartz.  J  "Expression 
continuity  and  the  formal  differentiation  of  algorithms  "  in 
Proceedings.  4th  ACM  POPL  Symposium.  ^ os  Angeles 
pp.  58-71.1977. 

[Rovner  78]  Rovner,  P.,  "Automatic  representation  selection  for 
associative  data  structures."  in  Proceedings  AFIPS  National 
Computer  Conference.  Anaheim.  California  pp  691  -701 
AFIPS  Press.  New  Jersey.  June  1978 

[Schonberg.  Schwartz  ft  Sharir8l]  Schonberg  E..  Schwartz.  J  T 
&  Sharir.  M  "An  automatic  technique  for  selection  of  data 
representations  in  SETL  programs  "  ACM  Transactions  or 
Programming  Languages  and  Systems  3.  (2).  April  1981 
126-143. 

[Sernadas  80]  Semadas.  A.,  "Temporal  aspects  of  logical 
procedure  definition,"  information  Systems  5.  (3).  1980. 
167-187. 

[Sintzoff80]  Smtzoff,  M.  "Suggestions  for  composing  and 
specifying  program  design  decisions  ”  in  4th  international 
Symposium  on  Programming.  Pans.  April  1980. 

[Wile  82]  Wile.  D.  S.  Program  developments  formal  explanations 
o'  implementations.  ISI  4676  Admiralty  Way.  Marina  del  Rey 
CA  90291  Technical  Report  RR-82-99  1962  To  appear  in 
CACM 


ggrwna 


